NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/2784

Internet Message Format | 1996-08-05 | 3.5 KB

Path: ix.netcom.com!netnews
From: [e-mail] (Mike Rubenstein)
Newsgroups: comp.lang.c
Subject: Re: Floating point calculation order
Date: Tue, 23 Jan 1996 22:11:22 GMT
Organization: Netcom
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <mjs.822427333@hubcap>
NNTP-Posting-Host: ix-dc18-03.ix.netcom.com
X-NETCOM-Date: Tue Jan 23  2:10:41 PM PST 1996
X-Newsreader: Forte Agent .99c/16.141

[e-mail] (M. J. Saltzman) wrote:

> [e-mail] (Tom Sanders) writes:
> %In article <[e-mail]>, [e-mail] (Mike Rubenstein) writes:
> %|> "Pavel A. Zemtsov" <[e-mail]> wrote:
> %|> >  Having declaration
> %|> >
> %|> >  double x, p, q, r;
> %|> >
> %|> > my compiler (cc on SCO 3.2) calculated following expression:
> %|> >
> %|> >  x = p * q / r;
> %|> >
> %|> > as p * (q/r); (I mean, it divided first, than multiplied). That
> %|> > resulted in precision loss.
> %|> >
> %|> > Is this legal behavior?
> %|>
> %|> Not in ANSI C, but it was legal in K&R. If memory serves, it was not
> %|> made illegal until very late in the standardizattion process so if
> %|> your compiler was written before the standard was finalized it may not
> %|> adhere to this.
>
> %I am a firm believer in not allowing a compiler to make these decisions for
> %me.  It's best to specify with parens the order of evaluation and not leave
> %it up to the compiler defaults.  I would actually prefer a compiler that
> %gave a warning if I did have an equation that could be evaluated in more
> %than 1 order (something I have not done in over 20 years).
>
> As I understand it, before ANSI, the compiler was free to even ignore
> parentheses and reorder the evaluation as long as the result was
> *mathematically* equivalent to the original expression.  So the only
> way to force an evaluation order was to use multi-line code with
> temporaries to hold the intermediate results.

This is correct.  Under K&R the only way to assure order of evaluation
was to break it up into separate statements.

> Would somebody explain under exactly what circumstances an ANSI
> compiler is and is not allowed to reorder evaluation?  My recollection
> was that parentheses forced evaluation order, but leaving them off
> allowed the compiler the freedom to reorder.  That's not what
> Rubenstein is claiming, though.
>
> Thus, in
>
>     x = p * q / r;
>
> the compiler is legally allowed to do the division first, but in
>
>     x = (p * q) / r;
>
> it is not, so that Sanders's strategy is effective in this case.

Not quite.  The compiler may never alter the order of evaluation
insofar as it is specifed in the standard except, of course, under the
as if rule, it may alter a program in any way as long as the result is
the same.

    x = p * q / r;

and

    x = (p * q) / r;

are equivalent.  In either case, the compiler must determin the value
of p * q and r and then do the division.  Note that there is no
required order on the evaluations of  p, q, and r.

> I also recall that the unary + was supposed to be useful in enforcing
> evaluation order, but I can't recall how it fits in.

This was proposed as part of the standard, but was dropped in favor of
disallowing changing the order completely.  As I said, if memory
serves this was very late in the standardization process and I
wouldn't count on it from any compiler written before the standard was
finalized even if it appears to be standard.


Michael M Rubenstein